The design and test of modern electronic devices, such as embedded processors (EP) and systems-on-a-chip (SoC), is a complex process involving many stages. For example, many systems, such as mobile devices, networking products, and modems require new embedded processors (EP). These EPs can either be general purpose, such as microcontrollers and digital signal processors (DSP), or application specific, using application specific instruction set processors (ASIP). Compared to general-purpose processors, ASIPs provide a tradeoff of computational performance and flexibility on the one hand and power consumption on the other. Therefore, ASIPs that are designed to execute specific tasks very efficiently can be found in a wide range of embedded systems.
However, designing systems with ASIPs is far more complex than assembling systems with standard processors. Typically, designing ASIPs comprises an iterative exploration in which hardware and software are explored and modified. This iterative process is referred to as an architecture exploration loop. The architecture exploration typically requires a software toolkit including: an assembler, linker, compiler, and simulator. If hardware and software are available, profiling results are acquired that usually lead to architecture modifications making the processor more efficient. To be consistent with these modifications, the software tools potentially need to be changed, as well.
Architecture description languages (ADL) have been established to aid the design of application-specific instruction-set processors (ASIP). Their main contribution is the automatic generation of the aforementioned software toolkit. Hence, the challenge in the design of such ADLs is to unambiguously capture the architectural information required for the toolkit generation in a single model.
One of the most challenging tasks in the design of ADLs is to capture the architectural information required for the software tool generation in a consistent and unambiguous way. In particular, the compiler and the instruction-set simulator (possibly on different abstraction levels) require the specification of the instructions' semantics; however, from very different points of view. While a compiler generally only needs information about what an instruction does, the simulator needs the details of how the instruction performs its particular task. It is a difficult task, if not impossible, to derive the semantics from the behavior (or vice versa). Therefore, no known conventional ADL solves this problem satisfactory. Examining the variety of ADLs, one can distinguish two major approaches: either redundancy is introduced by providing the semantical information separate from the behavioral information (e.g., a separate compiler and simulator specification), or the set of architectures that can be modeled is reduced by introducing a more formalized but inflexible description of the instruction behavior.
Most of the known conventional ADLs have originally been designed to aid the automation of a particular piece in the puzzle, and have then been extended to address larger parts of the embedded processor design. For example, some ADLs are well-suited for the automatic generation of a C compiler, although they impose major restrictions on, or are even incapable of, the generation of a cycle-accurate simulator.
After examination of today's state of the art, the existing ADLs can be separated into three categories: those which are capable of generating either a compiler or a cycle accurate simulator for contemporary processors, those which introduce redundancy by separating the semantic and the behavioral description, and those that combine semantics and behavior into a very restrictive grammar, hence sacrificing flexibility.
The first category includes languages such as ISDL (Instruction Set Description Language) or LISA 1.0, a former version of LISA (Language for Instruction Set Architectures). ISDL has been reported to generate efficient compilers, however, it is not capable of describing processors on cycle-accurate level. Hence, cycle accurate simulators cannot be generated.
The EXPRESSION ADL belongs to the second group, as a C compiler (EXPRESS) as well as a simulator (SIMPRESS) may be automatically generated. However, the views for both are separated into two different sections of the architecture description. While the simulator employs the information in a behavior section, the compiler relies on the existence of a so-called operation mapping, which associates the instruction with a tree of primitive operations similar to the nodes in a compiler's intermediate representation (IR). Naturally, this aids the task of code selection, but at the expense of the incorporation of redundant, purely compiler-specific information into the ADL.
By far the most approaches can be found in the third category. ADLs such as nML, MIMOLA, and PEAS-III define a very restricted grammar for the modeling of the instruction behavior, mostly by offering a set of predefined operators that can be combined into a behavioral description. For each operator, the functional behavior (for simulation) as well as its semantics (for compilation) are defined and usually contained in additional libraries. A further step is taken by a number of approaches employing so-called parameterizable generic processor cores, such as Xtensa architecture. Such cores usually have a fixed instruction-set, which can be extended by adding predefined or user-defined instructions. As software toolkit and synthesizable RTL model are available for the fixed part of the core, only the additional instructions must be taken into account. However, most of the user-defined instructions cannot be utilized by the compiler's code selector. The approaches in this category are rather suitable for the design of domain-specific processors than for ASIPs as they allow little flexibility for modeling complex pipelines and execution schemes.